Очередная интересная штука появилась на сайте проекта VMware Labs - утилита NUMA Observer, которая позволяет обнаружить виртуальные машины с перекрытием использования NUMA-узлов на хостах ESXi. При работе с тяжелыми нагрузками, требовательными к Latency, администраторы часто создают affinity-правила по привязке виртуальных машин к NUMA-узлам и ядрам CPU, чтобы они работали быстрее, с наименьшими задержками.

Но после сбоев и неполадок механизм VMware HA, восстанавливающий виртуальные машины на других хостах, может нарушить эту конфигурацию - там могут быть ВМ с уже привязанными NUMA-узлами, в результате чего возникнет перекрытие (overlap), которое полезно своевременно обнаружить.

С помощью NUMA Observer можно не только обнаруживать перекрытия по использованию ядер CPU и NUMA-узлов со стороны виртуальных машин, но и собирать статистики по использованию памяти дальнего узла и недостатке CPU-ресурсов (метрика CPU Ready). После анализа конфигураций и использования ресурсов, утилита генерирует алерты, которые администратор может использовать как исходные данные при настройке новой конфигурации NUMA-узлов.

Скачать NUMA Observer можно по этой ссылке. После установки сервис доступен через веб-консоль по адресу localhost:8443. Для его работы потребуется Java 8.

Многие из вас знакомы с продуктом VMware vRealize Operations, который предназначен для комплексного управления и мониторинга виртуальной инфраструктуры в различных аспектах. Одна из полезных возможностей этого решения - суперметрики (super metrics). Это те метрики, которые образованы путем каких-либо комбинаций обычных метрик через математическую формулу (например, какой процент CPU виртуальная машина отъедает от всего хоста ESXi). Для редактирования таких метрик используется super metric editor:

На ютуб-канале VMware Cloud Management появилась серия видеороликов, где в деталях рассказывается обо всех тонкостях суперметрик:

Список всех роликов, посвященных суперметрикам:

• Super Metrics Made Easy - Part 1 – Introduction
• Super Metrics Made Easy - Part 2 – Creating Your First Simple Super Metric
• Super Metrics Made Easy - Part 3 – Creating Your First “Real” Super Metric
• Super Metrics Made Easy – Part 4 – More Super Metrics 
• Super Metrics Made Easy – Part 5 – “This” Option in Super Metrics
• Super Metrics Made Easy – Part 6 – “If-Then-Else” Statement in Super Metrics
• Super Metrics Made Easy – Part 7 – Export-Import and Tips

Видео короткие - от полутора до семи минут, так что весь плейлист можно будет посмотреть за полчасика. Полный плейлист всех роликов о суперметриках находится по этой ссылке.

Недавно мы писали о новой версии решения для виртуализации и доставки настольных ПК и приложений VMware Horizon версии 2106. Помимо новых фич, в обновленной платформе появилось много приятных небольших нововведений, одно из них - это возможность вывести список всех событий VMware Horizon прямо в интерфейсе клиента:

Такого рода вещи стали возможны благодаря интерфейсам Audit Events API. Теперь для получения событий пользователям не нужно идти в базу данных с помощью SQL-запросов, а можно просто получать события через API.

Вильям Лам с помощью PowerCLI-сценария обработал файл с определениями событий C:\Program Files\VMware\VMware View\Server\LDAP\ldif\VDIEventStrings_en.ldf на сервере Connection Server и выяснил, что всего в Horizon есть на данный момент 858 типов событий. Эти события он вынес в отдельную табличку:

Также хотим напомнить вам об утилите VMware Horizon Event Notifier, которая соединяется с одной или несколькими базами данных Horizon View Event Database, вытаскивает оттуда выбранные администратором события (ошибки, предупреждения, инфо) и шлет письма на указанный email-адрес. При этом поддерживается возможность работы с несколькими БД, что позволяет собирать алерты с разных инсталляций VMware View (они же View Pods).

На сайте проекта VMware Labs обновилась очередная интересная утилита Storage Performance Tester, которая позволяет провести тестирование хранилищ в один клик на сервере VMware ESXi, получив метрики IOPS, latency и CPU cycles per I/O. В новой версии появилась поддержка адаптеров vnvme, а также исправления ошибок для ESXi 6.7.

С помощью данного средства можно автоматизировать шаги проведения тестирования, которые включают в себя развертывание кастомизированной ВМ, запуск нагрузки по вводу-выводу внутри нее и, собственно, функции по анализу результата тестирования производительности.

Результаты для полученных метрик выводятся в графическом интерфейсе в виде диаграмм и комментариев к ним:

Самое приятное - это то, что утилита запускается одной командой, после чего пользователь получает итоговый результат. Выглядит это так:

#./sperf.py HOSTNAME -d DatastoreName

Данное средство можно использовать как для решения проблем с действующей инфраструктурой хранилищ, так и для выяснения максимальных параметров производительности только что купленного железа (диски, контроллеры, компоненты сети хранения данных).

Ну и видео о том, как это все работает:

Для запуска Storage Performance Tester вам потребуется:

• Python 3
• sshpass
• 2 ГБ свободного пространства на диске
• Linux-окружение (ядро не старше 2.6.31)

Скачать Storage Performance Tester можно по этой ссылке.

При поддержке Антона Гостева сотрудники отдела маркетинга компании Veeam Software (а это, напомним, производитель средств для резервного копирования виртуальных инфраструктур номер 1) запустили конкурс «Обгони Гостева».

Неофициально конкурс стартовал внутри команды Veeam в феврале этого года. В своей рассылке на форуме Гостев рассказал об установке системы резервного копирования Veeam, которая показала максимальную производительность, достигающую 11.4 ГБ/с. Коллеги делились цифрами, которые встречали в своей практике, и искали новые данные, которые побьют цифры Гостева. Теперь в Veeam решили сделать этот конкурс публичным - ищется самая быстрая инфраструктура резервного копирования Veeam в России!

Участвуйте и расскажите о конкурсе коллегам. Перед участием прочитайте ответы на вопросы об условиях конкурса. Самые интересные случаи Veeam соберет и опубликует в статье. Три самых быстрых результата получат призы:

• Электросамокат XIAOMI
• Проектор Xiaomi Mi Smart
• Умная колонка Яндекс.Станция

Размещать результаты можно в Facebook или Twitter с хештегом #BeatTheGostev. Публикации с большим количеством лайков получат также шанс выиграть дополнительный секретный приз!

Конкурс продолжится до 30 сентября включительно, после чего будут подведены итоги. Кстати, скорость 11,4 ГБ/с для системы резервного копирования не является минимальным требованием для участия в конкурсе.

Участвовать!

Вильям Лам рассказал о том, как быстро и просто дать пользователям клиента VMware vSphere Client разрешения для просмотра пространств имен (namespaces) кластера vSphere with Tanzu.

Соответствующее разрешение нужно добавить в настройках Single Sign-On клиента:

Single Sign On->Users and Groups-> вкладка Groups

Находим там группу ServiceProviderUsers на второй странице и добавляем туда пользователей, которым мы хотим дать разрешение на просмотр неймспейсов:

После этого пользователю надо разлогиниться и залогиниться снова, а для просмотра пространств имен vSphere with Tanzu будет достаточно базовой роли Read Only для vSphere, которую можно дать разработчику (никаких изменений в конфигурацию чего бы то ни было такой пользователь внести не сможет):

Для пользователей и групп из Active Directory все работает точно таким же образом.

Среди открытых документов VMware появился очень интересный док - "vSphere Snapshots: Performance and Best Practices", в котором рассматривается весьма полезные многим администраторам аспекты - производительность снапшотов, а также, как правильно с ними обращаться. Мы часто пишем про это (1, 2, 3), а вот теперь есть и хороший документ с картинками.

Основные темы документа:

• Что такое снапшоты
• Какие есть форматы снапшотов
• Описание тестового окружения и рабочих нагрузок
• Результаты тестирования производительности
• Выводы по этим результатам

Итак, для тестирования использовались следующие рабочие нагрузки:

• FIO (стандартный тест производительности ввода-вывода)
• JVM (бенчмарк SPECjbb 2015)
• OLTP database (тест HammerDB)

Давайте взглянем на результаты тестирования производительности с точки зрения гостевой системы и ее приложений:

1. Число выдаваемых IOPS в зависимости от количества снапшотов для виртуальной машины (Random I/O):

В этом тесте и в последующих мы увидим, что снапшоты не влияют на производительность хранилищ VVols - такова природа этих хранилищ. А вот с VMFS и vSAN мы видим, что производительность падает, для VMFS - в три раза уже с первого снапшота, для vSAN - с третьего.

2. Для последовательного чтения vSAN ведет себя значительно лучше, а вот на VMFS производительность уже с первого снапшота падает в 2.5 раза, и дальше только хуже:

3. Для обработки запросов SPECjbb во всех трех случаях снапшоты не оказывали влияния на производительность:

4. По количеству транзакций в секунду тест HammerDB тоже показывает падение производительности хотя бы с одним снапшотом почти в 3 раза:

Интересно, что для хранилищ vSAN со снапшотами просадки по производительности для теста HammerDB нет.

5. Интересна также производительность гостевых ОС при соазднии и при удалении снапшотов:

Как мы видим, на VMFS критичен первый снапшот, и исходная производительность возвращается виртуальной машине только с удалением последнего снапшота. На vSAN производительность уменьшается и увеличивается постепенно, с изменением количества снапшотов.

Для больших блоков ввода вывода страдает только VMFS при последовательном чтении:

При последовательной записи больших блоков снапшоты влияют только на VMFS (при этом, только первый):

Ну и в заключение VMware приводит такую табличку потерь производительности для виртуальных машин с одним снапшотом:

Итак, очевидные выводы:

• Снапшоты - зло. Особенно для VMFS и иногда для vSAN.
• Особенное зло снапшотов проявляется для случайного чтения (Random reads), хотя и для последовательного все далеко не так хорошо.
• Хранилищам VVol все равно на снапшоты, производительность не падает.
• Зло, как правило, именно первый снапшот, дальше уже не так важно, сколько их, но производительность продолжает падать.
• При удалении снапшотов производительность ВМ возвращается к исходному уровню.

На сайте проекта VMware Labs обновилась утилита HCIBench 2.6, которая до этого обновлялась осенью прошлого года. Напомним, что это средство позволяет провести комплексный тест производительности отказоустойчивых кластеров хранилищ VMware vSAN, а также других конфигураций виртуальной инфраструктуры. О прошлой версии HCIBench 2.4 мы писали вот тут.

Суть работы HCIbench проста - пользователь задает параметры работы скрипта, а утилита дает команду средству Vdbench, содержащую инструкции о том, какие действия необходимо выполнить в кластере хранилищ. Это может вам пригодиться, например, когда вы хотите убедиться, что развернутая инфраструктура обеспечивает достаточную производительность для планируемой на нее нагрузки.

Давайте взглянем на новые возможности HCIBench 2.6:

• Сервер tomcat обновлен до версии 8.5.68
• Поддержка IPv6 для сетей ВМ и Management Network - как для DHCPv6, так и для link-local mode
• Поддержка режима развертывания multi-writer disk
• Улучшенная пре-валидация за счет перехода на govc
• Поддержка спецификации read/write io_limit для fio
• Исправлена ошибка при запуске в инфраструктуре VMC
• Улучшена система сбора диагностических бандлов в режиме отладки vSAN

Скачать VMware HCIBench 2.6 можно по этой ссылке.

На сайте проекта VMware Labs появилась новая утилита - Edge Services Observability. Она предназначена для мониторинга служб Edge Services (VMware Tunnel, Content Gateway, Secure Email Gateway, Reverse и Horizon Secure Access), которые запущены на модуле Unified Access Gateway - одном из ключевых компонентов решений VMware Horizon и Workspace ONE.

С помощью этого средства можно понять:

• Производительность шлюза на основе его загрузки
• Распределение трафика
• Влияние правил Device Traffic Rules на производительность

Основные возможности утилиты:

• Поставляется как готовый к настройке и развертыванию виртуальный модуль (Virtual Appliance) в формате OVA:

• Веб-портал для управления инстансами Unified Access Gateway (UAG):

• Дашборды для визуализации метрик компонентов VMware Tunnel и VMware Horizon на базе Grafana:

• Возможность настройки алертов на основе различных условий, что позволяет оперативно выявлять аномалии

Скачать VMware Edge Services Observability можно по этой ссылке. Более подробная информация о продукте доступна тут.

Это гостевой пост нашего партнера - сервис-провайдера ИТ-ГРАД, предоставляющего виртуальные машины в аренду по модели IaaS.

В декабре прошлого года компания Red Hat официально заявила о досрочном прекращении поддержки популярного дистрибутива Linux, CentOS, — на восемь лет раньше запланированного. Дистрибутив должен был «прожить» до 2029-го, однако его перестанут поддерживать уже в конце этого года. А значит, пользователи CentOS перестанут получать обновления, включая исправление ошибок в ядре и ПО.

Эта новость крайне взбудоражила ИТ-сообщество. Чтобы как-то сгладить негативную реакцию, Red Hat даже предложила пользователям перейти на CentOS Stream. Технолосфера отреагировала на это событие по-своему — участники рынка open source ПО поспешили предложить юзерам собственные альтернативы «брошенной» CentOS:

• Almalinux — разработка компании Cloudlinux, первый релиз которой состоялся в марте этого года.
• «Отец» CentOS Грег Курцер тоже не остался в стороне и заявил о создании Rocky Linux. Позже стало известно, что Курцер даже создал стартап Ctrl IQ — планируется, что он и будет спонсировать проект и ПО.
• ИТ-гигант Oracle, который более 10 лет занимается развитием Oracle Linux, выпустила бесплатную утилиту для сисадминов, который позволяет бесшовно переехать с CentOS на версию от Oracle.

Теперь в новостях о CentOS отметилась и американская Virtuozzo, специализирующаяся на разработке ПО для виртуализации. Компания предоставила всем желающим бесплатный доступ к VzLinux 8. Представители компании сообщают, что их разработка может полностью заменить CentOS 8 и полностью совместима с RHEL.

VzLinux — это серверный дистрибутив ОС, который можно запускать как на физических машинах и ВМ, так и в контейнерах. Вдобавок разработчики предоставляют пользователям утилиту для безболезненной миграции на собственный дистрибутив.

Оригинал статьи в блоге ИТ-ГРАД.

Многие Enterprise-администраторы настраивают автоматический регулярный бэкап решения для виртуализации и агрегации сетей VMware NSX-T из консоли, что описано, например, вот тут.

Между тем, как правильно заметил автор virten.net, при неудачном завершении задачи резервного копирования администратор не получает нотификации даже в дэшборде в разделе алармов.

В случае падения задачи бэкапа информация об этом доступна только в разделе Backup & Restore настроек:

Эту информацию можно получить и через API:

> GET /api/v1/cluster/backups/history HTTP/1.1
{
  "cluster_backup_statuses": [
    {
      "backup_id": "5cf21742-091a-b9b9-1f24-ad75ede2d23b-1615489436",
      "start_time": 1615489436085,
      "end_time": 1615489440865,
      "success": false,
      "error_code": "BACKUP_AUTHENTICATION_FAILURE",
      "error_message": "either backup server login failed or unauthorized access to backup directory"
    }
  ],
  "node_backup_statuses": [
    {
      "backup_id": "5cf21742-091a-b9b9-1f24-ad75ede2d23b-1615403036",
      "start_time": 1615403036017,
      "end_time": 1615403354709,
      "success": true
    }
  ],
  "inventory_backup_statuses": [
    {
      "backup_id": "inventory-1615490636",
      "start_time": 1615490636254,
      "end_time": 1615490641758,
      "success": true
    }
  ]
}

В данном примере неудачно завершился процесс резервного копирования кластера, поэтому нужно смотреть не только на статусы узлов (кстати, времена указаны в миллисекундах).

Коллега с virten.net написал сценарий на Python для Nagios, который позволит вам проверить статус последнего бэкапа кластера NSX-T, а также посмотреть возраст последней имеющейся резервной копии:

usage: check_nsxt_backup.py [-h] -n NSX_HOST [-t TCP_PORT] -u USER -p PASSWORD
                            [-i] [-a MAX_AGE]

# python check_nsxt_backup.py -n nsx.virten.lab -u audit -p password
NSX-T cluster backup failed
NSX-T node backup is to old (1461 minutes)

Когда вышло обновление VMware vSphere 7 Update 2, мы рассказывали о новых оптимизациях для процессоров AMD EPYC, которые были сделаны в платформе виртуализации на базе гипервизора ESXi. Реализация поддержки новых функций CPU идет в соответствии с развитием технологий аппаратной виртуализации AMD, которую VMware поддерживает наравне с таковой от Intel.

Недавно VMware выпустила отдельный документ "Performance Optimizations in VMware vSphere 7.0 U2 CPU Scheduler for AMD EPYC Processors", где рассказано, какие были сделаны оптимизации, и как именно они влияют на увеличение производительности:

В документе есть много интересных тестов (большинство из них сделано с помощью утилиты VMmark3), приведем ниже результаты некоторых из них:

• Увеличение производительности одной ВМ для БД Microsoft SQL Server под нагрузкой HammerDB (тут и далее нормировано к показателям vSphere 7 Update 1):

• Несколько виртуальных машин с 8 vCPU на борту и нагрузкой HammerDB - производительность при увеличении числа виртуальных машин на хосте:

Использование базы данных CockroachDB на 6-узловом кластере, прирост производительности до 50%:

Тестирование кластера Kubernetes c узлами по 64 воркера с помощью бенчмарка Weathervane (на 16 инстансах приложений прирост производительности - более 40%):

В общем, документ очень интересный - посмотрите.

Оказывается у VMware есть утилита TENS, что расшифровывается как Traffic Emulator for Network Service. Это еще один эмулятор сетевой нагрузки от VMware, который, в отличие от аналогов, сфокусирован на паттернах нагрузки, а не только на генерации объема и интенсивности сетевого потока. В основном, подобные средства предназначены для того, чтобы выяснить максимальные параметры сетевой нагрузки, которые могут выдержать те или иные компоненты. Кроме того, при генерации нагрузки эти средства, как правило, работают с одним приложением, когда речь идет о задании паттернов.

VMware же решила сделать утилиту для симуляции паттернов нагрузки для нескольких приложений, чтобы изучать их поведение в условиях, приближенных к реальным. Проект TENS распространяется как Open Source и доступен в репозитории на GitHub.

Продукт состоит из двух компонентов:

• Traffic Engine Controller (TEC) - это мозг всей системы, который управляет распределенными воркерами (их может быть сколько угодно) и предоставляет доступ сторонним системам через API.
• Traffic Engines Datapath (TE-DP) - компоненты непосредственно эмулирующие трафик нагрузки в соответствии с реальными паттернами.

TENS может эмулировать несколько браузерных сессий, клиентов, соединений и запросов на уровнях L4 и L7. Это позволяет заполнить разрыв между тестовым окружением, предпроизводственной средой, которую надо хорошо оттестировать, и производственным окружением, где приложения должны выдерживать требования к нагрузке по TCP/HTTP/UDP. Также TENS выводит отчет о метриках и ошибках для компонентов тестируемой системы.

Основные возможности VMware Traffic Emulator for Network Service:

• Функции для валидации и отчетности серверов балансировки нагрузки и серверов приложений.
• Генерация трафика от нескольких пользователей, нескольких сессий одного пользователя и нескольких соединений/запросов в рамках одной сессии - все это для нескольких вычислительных узлов.
• Комплексные метрики, выявление аномалий и мониторинг в реальном времени с одного узла с возможностью сообщения об ошибках как на уровне L4 (TCP/UDP), так и на L7 (HTTP/HTTPS).
• Возможность генерации L7-траффика с разных исходных IP и пространств имен, с внедренными куками, хэдерами и параметрами запросов в измерениях RPS, TPS, TPUT и CPS.
• Возможность запуска в нескольких процессинговых узлах, которые контролируются единой точкой доступа через API.
• Поддержка трафика http/1, http/1.1 и http/2 на уровне L7.
• Поддержка SSL версий SSLv2, SSLv3, TLSv1, TLSv1.0, TLSv1.1, TLSv1.2 и TLSv1.3 на уровне L7.
• Поддержка взаимной аутентификации сервер-клиент за счет проверки сертификатов на уровне L7.
• Возможность эмуляции аплоадов и загрузок больших UDP-датаграмм с несколькими одновременными подключениями на уровне L4.
• Утилита TENS упакована для использования в контейнеризованных системах - как в облачных, так и онпремизных.
• Возможность управлять утилитой через REST API для автоматизации операций и интеграции в общую инфраструктуру рабочих процессов тестирования.
• Поддержка SSL session reuse и persistence validation, что позволяет более безопасно организовывать процесс тестирования.

Скачать VMware TENS можно по этой ссылке.

На сайте проекта VMware Labs обновился основной клиент VMware vSphere на базе технологии HTML5 (он же vSphere Client в составе платформы VMware). Напомним, что старый клиент Web Client на базе Adobe Flex ушел в прошлое, и VMware предлагает использовать только новый клиент для управления виртуальной инфраструктурой.

Кстати, VMware vSphere HTML5 Web Client версии 5.0 (build 15670023) - это первое обновление клиента за довольно долгое время. Давайте посмотрим, что там появилось нового:

• Обновлена документация (в том числе инструкции, где находятся файлы и сервисы клиента)
• Добавлен новый язык для функции Code Capture - теперь записанные во время сессии действия могут транслироваться в код на языке Go.
• PowerActions - это новый механизм интеграции PowerCLI и vSphere Client. Теперь в клиенте есть функциональность по запуску отдельных команд и сценариев PowerCLI, а также функции их хранения в библиотеке скриптов. Исполнение кастомных действий скриптов можно привязать к объектам из inventory в клиенте.
• Функцию PowerActions надо включать отдельно при развертывании клиента (см. документ PowerActions_documentation_Fling50.pdf).

Базовая операционная система виртуального модуля vSphere Client была заменена на Photon OS, поэтому апгрейд с прошлой версии не поддерживается - придется развертывать все по-новой.

Загрузить новую версию клиента VMware vSphere HTML5 Web Client 5.0 можно по этой ссылке. Инструкции по установке и использованию доступны тут. Также много всего интересного есть в комбо-боксе выбора компонентов загрузки:

Некоторое время назад мы опубликовали статью о протоколах NTP и PTP, которые отвечают за работу служб точного времени для хоста ESXi и виртуальных машин.

Оказывается, в весеннем обновлении VMware vSphere 7 Update 2 появилась поддержка нового механизма Precision Time for Windows. Раньше для почти всех задач в виртуальных машинах использовалась связка NTP+Active Directory, которая работает отлично в подавляющем большинстве случаев. NTP обеспечивает точность на уровне миллисекунд, а если нужна какая-то большая точность (например, финансовые приложения), то тут можно использовать специальное оборудование с поддержкой PTP (Precision Time Protocol).

VMware решила сделать еще одно улучшение для пользователей, которым требуется повышенная чувствительность служб точного времени. Теперь в vSphere 7 Update 2 есть поддержка Precision Time for Windows - механизма, который улучшает точность синхронизации времени в ОС Windows.

Сервис Windows Time Service (W32Time) - это служба, которая опирается на NTP и предоставляет клиентам ОС информацию о точном времени. В основном она нужна для синхронизации времени между хостами в Active Directory, но уже вышла за рамки этих задач и может быть использована приложениями. Архитектура W32Time построена на базе плагинов, что означает, что DLL-библиотека может быть зарегистрирована как провайдер служб точного времени. Это могут быть как чисто программные решения, так и комплексные системы со специальным оборудованием с поддержкой PTP-протокола.

API-интерфейсы для разработки таких плагинов находятся в открытом доступе, каждый может написать свой собственный. Вот и VMware разработала свой VMware Time Provider (vmwTimeProvider), который поставляется вместе с VMware Tools для ВМ на базе Windows. Он получает время от виртуального устройства Precision Clock (оно появилось еще в vSphere 7.0) и передает его на сторону W32Time по закрытому и быстрому каналу (на базе технологии паравиртуализации), минуя сетевой стек.

vmwTimeProvider - это плагин, работающий в пространстве user-space. По идее такое устройство требовало бы собственный драйвер, но у VMware есть собственный паравиртуализованный интерфейс, который использует преимущества технологии Memory-mapped I/O (MMIO), оптимизированной под операции чтения.

Устройство Precision Clock получает время от ядра гипервизора (VMkernel), одним из источников является устройство HyperClock, поставляющее в ядро системное время. Таким образом, если вы настроите VMkernel и HyperClock на получение времени через Precision Time Protocol (PTP), то устройство Precision Clock будет передавать его в виртуальные машины с большой точностью.

Ну и в завершение надо отметить, что vmwTimeProvider не выбран по умолчанию при установке, так как он не нужен системам без специальных требований к службам времени.

На днях компания VMware обновила средство VMware OS Optimization Tool до версии b2002 на сайте проекта VMware Labs. Напомним, что эта утилита нужна для подготовки гостевых ОС к развертыванию и проведению тюнинга реестра в целях оптимизации производительности, а также отключения ненужных сервисов и запланированных задач. О прошлом ее релизе мы писали вот тут.

Давайте посмотрим, что нового в мартовской версии VMware OSOT b2002:

• Пункт "Block all consumer Microsoft account user authentication" отключен по умолчанию, чтобы пользователи не испытывали проблем с логином в Edge и Windows store.
• Также по умолчанию отключен пункт "Turn off Thumbnail Previews in File Explorer", что приводило к не ожидаемому для пользователей поведению.
• Для не-Enterprise изданий Windows 10, обновление KB4023057 устанавливает новое приложение Microsoft Update Health Tools. Теперь добавлена логика, позволяющая убедиться, что служба Windows Update Medic Service отключена при отключении обновлений, включая ситуации перещелкивания включенной/отключенной службы Windows Updates на вкладке Update.
• Шаблоны Windows 8 и 8.1 были удалены из списка встроенных шаблонов. Чтобы работать с этими версиями, вам понадобится OSOT версии b1130.
• Также из репозитория были удалены старые шаблоны Windows 10 1809-2004-Server 2019 и Windows 10 1507-1803-Server 2016.
• Поправлена ошибка с обработкой файла тем, который обновлялся задачей Generalize, затиравшей предыдущие оптимизации.
• Поправлена ошибка с файлом ответов, который теперь корректно обрабатывает имя администратора для задачи Generalize.
• Удален старый код для GPO Policy corruption.
• Убрано окошко CMD.exe, которое появлялось при логине.
• Пофикшена ошибка, когда Windows Store Apps некорректно удалялись для Windows 10 version 20H2

Скачать VMware OS Optimization Tool версии b2002 можно по этой ссылке.

У компании VMware есть полезная бесплатная электронная книга PowerCLI Cookbook for VMware vSAN, посвященная управлению инфраструктурой отказоустойчивых хранилищ с помощью сценариев, которая будет полезна всем администраторам хранилищ виртуальных сред vSphere / vSAN.

В книге на 127 страницах подробно рассказывается о командлетах для управления всеми аспектами хранилищ с помощью PowerCLI. В документе 3 основных блока:

• Configuration Recipes - разбор примеров использования сценариев для настройки самого окружения vSAN, а именно:
  • Настройка vSAN в новом или существующем кластере
  • Добавление хостов
  • Настройка сетевого окружения
  • Выделение дисков под хранилища
  • Настройка HA и DRS
  • Настройка дедупликации и компрессии
  • Настройка шифрования
  • Конфигурация vSAN Performance Service
• Operational Recipes - это практические примеры сценариев для ежедневного использования и подробный разбор их параметров, а также описание процедур, которые нужно регулярно выполнять в кластере.
• Reporting Recipes - это набор рецептов для вывода информации о конфигурациях, метриках и состояниях, а также представления данных в удобном виде.

Скачивайте PowerCLI Cookbook for VMware vSAN - штука полезная.

Осенью прошлого года мы писали о выходе бета-версии операционной системы VMware Photon OS 4.0 Beta, использующейся в виртуальных модулях VMware (Virtual Appliances), которые реализуют различные вспомогательные сервисы. 

На днях вышла финальная версия Photon OS 4.0, давайте посмотрим, что там появилось нового:

Главные улучшения

• Ядро реального времени для приложений телекома и vRAN (Virtual Radio Network)

  Наступает эра 5G, и VMware сделала в Photon OS 4.0 возможности поддержки телеком-приложений реального времени на уровне ядра (Photon Real Time kernel). Это позволит технологиям vRAN (Virtual Radio Network) использовать возможности ОС Photon при развитии инфраструктуры 5G-операторов. Для этого появился специальный kernel flavor, который называется "linux-rt". Вместе с остальными компонентами (userspace-пакетами) этот режим называется Photon Real Time (RT).

• Безопасность
  
  Photon 4.0 получила поддержку таких технологий по обеспечению безопасности, как SELinux, Security Encrypted Virtualization – Encrypted Status и Intel Software Guard Extensions. Обязательная система контроля доступа, прошитая на уровне ядра, позволяет SELinux дать администраторам гранулярный и гибкий доступ к ресурсам. Также Photon OS позволяет из коробки, на уровне политик, обеспечить нужды приложений в изоляции. Также поддерживается SELinux для контейнеров, что было протестировано для docker, containerd и runc.
  
  Поддержка драйверов Intel SGX drivers позволяет приложениям использовать ресурсы CPU для создания "анклавов" - полностью защищенных модулей исполнения, недоступных на аппаратном уровне другим процессам.
  

• Обновленный механизм сетевой конфигурации
  
  Теперь Photon 4.0 имеет полностью переработанную библиотеку network configuration management library вместо netmgr, которая предоставляет API для большинства задач конфигурации (IP-адреса, маршруты, DNS и прочее). То есть вместо файлов конфигурации можно использовать API.

• Оптимизации производительности для решения vSphere with Tanzu
  
  Исторически Photon ОС имела специальный контекст ядра linux-esx, который был специальным образом оптимизирован для работе на платформе VMware ESXi точки зрения производительности и предоставляемых возможностей. В Photon 4.0 то же самое появилось и для контейнерной среды исполнения vSphere with Tanzu, например, уменьшение времени запуска для контейнеров и приложений.

• Прочие улучшения
  
  - Поддержка Raspberry Pi 4
  - Для ARM-архитектуры доступны образы в формате OVA и AMI
  - В tdnf добавлена поддержка расширенной конфигурации сервисов безопасности
  - Ядро обновлено до версии 5.10 (декабрь 2020)

Установщик и обновления

• Поддержка распределенных билдов с использованием Kubernetes
• Доступность установщика Photon OS в виде RPM-пакета
• Поддержка нескольких дисков в image builder
• Поддержка самоподписанных SSL-сертификатов в kickstart-установке из ISO-образа
• Для RPM используется механизм zstd по умолчанию

Состав пакета

• Готовые образы для облачного развертывания в Microsoft Azure (новое), Google Compute Engine (GCE), Amazon Elastic Compute Cloud (EC2) и продуктах VMware (vSphere, Fusion и Workstation)
• Критические обновления следующих пакетов:
• Linux kernel 5.10 LTS
• Glibc 2.32
• systemd 247
• Python3 3.9
• Openjdk : 1.8.0.265, 11.0.9
• Openssl : 1.1.1
• Cloud-init: 20.4.1
• GCC: 10.2.0
• Обновленные версии основных пакетов, доступные в репозиториях

Скачать VMware Photon OS 4.0 в виде OVA-пакета или ISO-образа можно по этой ссылке.

Продолжаем рассказывать о лучшем в отрасли решении для создания программных хранилищ под виртуальные машины на базе хост-серверов ESXi - StarWind Virtual SAN for vSphere. Как многие знают, с какого-то момента StarWind стала поставлять свое решение для платформ VMware в виде виртуального модуля (Virtual Appliance) на базе Linux, который реализует основные сервисы хранения, дедупликации и компрессии, а также отказоустойчивости и обеспечения надежности данных в виртуальных машинах.

Для виртуального модуля StarWind работа механизма дедупликации и компрессии обеспечивается средствами Linux-движка Virtual Data Optimizer (VDO), который появился относительно недавно. Это удобный и надежный способ экономии дискового пространства за счет использования дополнительных емкостей оперативной памяти на хосте.

Для начала вам нужно определиться с оборудованием хостов ESXi, где вы будете развертывать виртуальные модули StarWind. Как вы понимаете, в целях обеспечения отказоустойчивости таких узлов должно быть как минимум два.

Что касается HDD и SSD-дисков, то нужно также спланировать конфигурацию RAID на хранилище хостов. Сделать это можно в соответствии с рекомендациями, описанными в базе знаний StarWind. Вы можете использовать программный или аппаратный RAID, о настройках которого мы расскажем ниже.

Что касается дополнительной оперативной памяти на хосте ESXi, то нужно выбирать ее объем, исходя из следующих критериев:

• 370 МБ плюс дополнительные 268 МБ на каждый 1 ТБ физического хранилища
• Дополнительно 250 МБ на 1 ТБ физического хранилища, если включена дедупликация (UDS index)

То есть для 4 ТБ физического хранилища с дедупликацией вам понадобится:

370 MB + 4 * 268 MB +4 * 250 MB = 2 442 MB RAM

Итого 2,4 ГБ оперативной памяти дополнительно к памяти под ОС виртуального модуля. Вообще, StarWind рекомендует 8 ГБ памяти для виртуального модуля - 4 ГБ на машину и 4 ГБ на движок VDO для работы с хранилищем.

Один VDO-том может работать с хранилищем до 256 ТБ, что покрывает максимум потребностей в рамках хранилищ на базе серверов. Также StarWind очень рекомендует использовать дисковые массивы All-flash или NVMe-оборудование.

Общее правило развертывания таких хранилищ таково:

• Под VDO: аппаратный или программный RAID (LVM или mdraid)
• Над VDO: "толстые" (thick) диски StarWind Virtual SAN в режиме stand-alone или HA

Надо понимать, что сам том VDO - это тонкий диск, растущий по мере наполнения, поэтому устройство под ним должно иметь расширяемую природу (MD RAID, LVM).

Примерная схема отказоустойчивого решения StarWind Virtual SAN for vSphere на базе 2 узлов выглядит так:

После того, как вы установите StarWind Virtual SAN, настроите виртуальную машину и StarWind Management Console, нужно будет настроить аппаратный или программный RAID для хранилища.

Если вы используете аппаратный RAID, то просто создайте виртуальный диск для ВМ StarWind Virtual SAN на его хранилище, но обязательно типа "Thick Provisioned Eager Zeroed" (также вы можете использовать RDM-диск):

Если же вы будете использовать программный RAID, то нужно будет использовать HBA или RAID-контроллер в режиме DirectPath I/O passthrough, чтобы получить прямой доступ к дискам и собрать на их базе RAID-массив.

Для этого вам нужно будте выбрать правильный HBA/RAID-контроллер как PCI-устройство:

И пробросить его напрямую в виртуальную машину StarWind:

После этого в StarWind Management Console можно будет собрать RAID нужного вам уровня:

Рекомендации тут такие:

После этого в виртуальном модуле StarWind на полученном хранилище нужно будет создать VDO-устройство с нужными вам параметрами:

vdo create –activate=enabled –deduplication=enabled –compression=disabled –emulate512=enabled –indexMem=%size% –vdoLogicalSize=%size% –device=%yourdevice% -n=%name%

Здесь мы видим, что создается устройство с включенной дедупликацией, выключенной компрессией, нужным размером индексной памяти и заданного объема.

После создания это устройство надо отформатировать в XFS со следующими параметрами:

Далее вы можете создавать хранилище StarWind на этом устройстве и (опционально) сделать его реплику на партнерском узле в режиме HA. Также рекомендуется выставить настройку Disk.DiskMaxIOSize на хосте ESXi

В значение 512:

Ну и про оптимизацию производительности I/O-планировщика прочитайте вот эту статью базы знаний StarWind. Если вам интересен процесс создания хранилищ с дедупликацией и компрессией на базе StarWind Virtual SAN в стиле "от и до", то рекомендуем прочитать вот эту статью.

Команда PowerCLI компании VMware на днях выпустила обновление средства vSphere Desired State Configuration (DSC) версии 2.2. Механизм DSC есть в экосистеме Windows, начиная еще с Windows Server 2012 R2. С помощью него можно мониторить и управлять конфигурациями систем посредством специальных конфигурационных файлов на базе PowerShell, которые имплементируются через движок Local Configuration Manager (LCM), который должен быть на каждом хосте.

У VMware этот механизм работает несколько иначе, в качестве LCM используется прокси-хост, поскольку LCM не запустить ни на vCenter Server Appliance, ни на ESXi:

Так работал механизм до текущего момента, когда пользователям приходилось разворачивать отдельную Windows-машину под LCM. Но теперь появился модуль VMware.PSDesiredStateConfiguration, который предоставляет пользователям набор командлетов, чтобы скомпилировать и исполнить конфигурацию DCS без использования DSC Local Configuration Manager. Это позволяет использовать как Windows, так и Linux-машину в качестве прокси.

При этом пользователям по-прежнему предоставляется возможность использовать как vSphereDSC с движком PowerShell LCM, так и модуль VMware.PSDesiredStateConfiguration.

Давайте посмотрим, что нового появилось в DCS версии 2.2:

1. Новые ресурсы PowerCLI модуля

Вот они:

1. DatastoreCluster - создание, изменение, апдейт или удаление Datastore cluster
2. DatastoreClusterAddDatastore - добавление датастора к Datastore cluster
3. DRSRule - создание, изменение, апдейт или удаление правил DRS
4. VMHostVdsNic - изменение, апдейт или удаление "VMKernel nic" на vSphere Distributed switch
5. VMHostStorage - включение или отключение программного iSCSI-адаптера 
6. VMHostIScsiHbaVMKernelNic - используется для bind/unbind адаптеров VMKernel Network Adapters к указанному iSCSI Host Bus Adapter

2. Исправления ошибок

Поправлены ошибки в следующих командлетах:

• VMHostVDSwitchMigration 
• VMHostVssTeaming
• NfsDatastore

3. Операция Install/Update для модуля VMware vSphereDSC

Установка модуля теперь делается так:

Install-Module -Name VMware.vSphereDSC

Обновление вот так:

Update-Module -Name VMware.vSphereDSC

4. Новый модуль VMware.PSDesiredStateConfiguration

Как было сказано выше, теперь вы можете использовать Windows или Linux-машину без LCM для использования механизма DCS. Установить модуль можно следующей командой:

Install-Module -Name VMware.PSDesiredStateConfiguration

Новый командлет New-VmwDscConfiguration создает объект VmwDscConfiguration, который содержит информацию о конфигурации. Эту конфигурацию можно задать в ps1-файле и передать ее данному командлету. Например:

$config = New-VmwDscConfiguration -Path ./Site-A.ps1

Командлет Start-VmwDscConfiguration запускает исполнение конфигурации:

Start-VmwDscConfiguration -Configuration $config

Есть командлет Test-VmwDscConfiguration для проверки соответствия текущей конфигурации описанной:

Test-VmwDscConfiguration -Configuration $config

Можно также использовать параметр -Detailed для вывода полной информации по соответствию:

Test-VmwDscConfiguration -Configuration $config -Detailed

5. Новая динамическая конструкция vSphere Node

С помощью vSphere Node можно указать объект VINode (сервер vCenter или хост ESXi) и применить соответствующую конфигурацию к нужному узлу vSphere. Это дает следующие возможности:

• Персистентные сессии

Раньше для каждого подключения каждый ресурс требовал параметров учетной записи для установки сессии VISession. Теперь же если вы используете Vmware.PSDesiredStateConfiguration то можно создать персистентную VISession, которую можно использовать для всех ресурсов DCS.

• Не нужны файлы MOF

Поскольку LCM теперь не используется, то и для командлета New-VmwDSCconfiguration они не требуются. Конфигурация может храниться в переменной, либо в ps1-файле.

Скачать VMware vSphere DSC 2.2 можно по этой ссылке.

На сайте VMware Labs появился интересный инструмент Virtualized High Performance Computing Toolkit, который может оказаться полезен компаниям, использующим VMware vSphere для организации высокопроизводительных вычислений (High Performance Computing, HPC). Такие комплексные вычислительные задачи, как правило, вовлекают параллельные вычисления, аппаратное ускорение (такое как GPU и FPGA), а также используют высокоскоростные каналы, такие как RDMA.

Все это требует определенных конфигураций VMware vSphere, для настройки которых и нужно данное средство. С помощью него, используя vSphere API, можно дать администраторам инструменты по сопровождению задач HPC, таких как клонирование ВМ, настройка Latency Sensitivity, сайзинг виртуальных машин по CPU и памяти и многое другое.

Основные возможности тулкита:

• Настройка устройств PCIe в режиме DirectPath I/O, таких как GPGPU, FPGA и RDMA
• Настройка NVIDIA vGPU
• Настройка RDMA SR-IOV (Single Root I/O Virtualization)
• Настройка PVRDMA (Paravirtualized RDMA)
• Простое создание и уничтожение кластеров HPC с помощью файлов конфигураций
• Выполнение задач vSphere, таких как клонирование, настройка vCPU, памяти, резерваций, shares, Latency Sensitivity, обычного и распределенного виртуального коммутатора, сетевых адаптеров и конфигураций

Например, клонирование 4 виртуальных машин с заданными кастомизациями CPU и памяти, а также добавлением NVIDIA vGPU с профилем grid_p100-4q выглядит так:

vhpc_toolkit> clone --template vhpc_clone --datacenter HPC_Datacenter --cluster COMPUTE_GPU_Cluster --datastore COMPUTE01_vsanDatastore --memory 8 --cpu 8 –-file VM-file
vhpc_toolkit> vgpu --add --profile grid_p100-4q --file VM-file

Для использования тулкита вам понадобится ОС Linux или Mac. Скачать Virtualized High Performance Computing Toolkit можно по этой ссылке.

Наш постоянный читатель Сергей обратил внимание на то, что на днях компания VMware выпустила обновление своего главного фреймворка для управления виртуальной инфраструктурой с помощью сценариев - PowerCLI 12.2. Напомним, что о прошлой версии PowerCLI 12.1 осенью прошлого года мы писали вот тут.

Давайте посмотрим, что нового появилось в обновленном PowerCLI 12.2:

1. Поддержка VMware Horizon

Модуль PowerCLI для управления инфраструктурой Horizon теперь поддерживается для macOS и Linux OS.

2. Инфраструктура VMware Cloud

Появилась поддержка одного из самых популярных сервисов для обеспечения катастрофоустойчивости датацентров - DRaaS. Новые командлеты позволяют включать/отключать DRaaS в виртуальном датацентре VMC SDDC, а также добавлять и удалять инстансы SRM (Site Recovery Manager).

Вот так выглядит включение DRaaS:

Управление инстансами SRM происходит с помощью командлетов:

• Get-VmcSddcSiteRecoveryInstance
• New-VmcSddcSiteRecoveryInstance
• Remove-VmcSddcSiteRecoveryInstance

3. Поддержка VMware vSphere

• Расширенная поддержка vSphere Lifecycle Manager (vLCM)
  • Новые командлеты для экспорта и импорта состояния кластера
  • Новые командлеты для получения рекомендаций vLCM (Get-LcmClusterDesiredStateRecommendation)
  • Новые командлеты для получения аппаратной совместимости компонентов со стороны vLCM
  • Улучшенный командлет Set-Cluster для добавления кастомного репозитория ROBO-окружений
• Расширенная поддержка параметров OVF для объектов Content Library
• Добавлена поддержка шаблонов ВМ в Content Library
• Операция Foreach-object -Parallel теперь поддерживается

Вот так выглядит экспорт состояния кластера:

А вот так импорт:

4. Управление рабочими нагрузками

• Новые командлеты для управления лимитами пространств имен:
• Get-WMNamespaceLimits
• Set-WMNamespaceLimits

5. Поддержка NSX-T

• Теперь поддерживаются API компонента NSX-T global manager

Больше подробностей и примеров использования новых фич вы можете найти вот в этой статье. Скачать VMware PowerCLI 12.2 можно по этой ссылке.

Администраторы VMware vSphere в больших инфраструктурах иногда используют кластеры Windows Server Failover Clusters (WSFC) на базе RDM-дисков, которые доступны для хостов VMware ESXi. Ранее они назывались Microsoft Cluster Service (MSCS). При использовании таких кластеров время загрузки хоста ESXi может вырасти аж до целого часа, если не поставить этим LUN статус Perennially reserved.

Суть проблемы в том, что WSFC ставит SCSI-3 reservations для своих LUN, используемых активным узлом, и если ESXi видит эти тома (то есть они не отмаскированы для него), то он безуспешно пытается получить к ним доступ. Для этого он делает несколько попыток при загрузке, пока не решает перейти к следующим томам. Статус этих операций вы можете увидеть, если нажмете Alt+F12 при загрузке хоста:

Xavier Avrillier написал статью о том, как с помощью esxicli/PowerCLI пометить такие тома как Perennially reserved, чтобы ESXi пропускал их при сканировании (об этом также рассказано в KB 1016106).

Сначала вам надо узнать LUN canonical name устройства. Делается это следующей командой PowerCLI:

PS> Get-VM MSCS-Node-1 | Get-HardDisk -DiskType RawPhysical | select scsicanonicalname
ScsiCanonicalName

  —————–

  naa.60001xxxxxxxxxxxxxxxxxxxxxxxacbc

  naa.60001xxxxxxxxxxxxxxxxxxxxxxxacbb

  naa.60001xxxxxxxxxxxxxxxxxxxxxxxacba

  naa.60001xxxxxxxxxxxxxxxxxxxxxxxacbd

  naa.60001xxxxxxxxxxxxxxxxxxxxxxxacb9

  naa.60001xxxxxxxxxxxxxxxxxxxxxxxacb8

Далее для нужного id-устройства устанавливается статус Perennially reserved через esxcli:

esxcli storage core device setconfig -d naa.id –perennially-reserved=true

Но удобнее это же сделать и через PowerCLI (ищем диски у машин по шаблону MSCS-Node-*):

PS> Set-PerenniallyReserved -PerenniallyReserved $True -VMHost (Get-VMHost) -HardDisk (Get-VM MSCS-Node-* | Get-HardDisk -DiskType RawPhysical)

Ну а для тех, кто хочет использовать vSphere Client, недавно появилась опция "Mark as Perennially Reserved" в разделе Storage Devices клиента:

Главное - не ошибитесь в выборе LUN, если вы отметите не то - это может привести к весьма печальным последствиям.

Источник.

Иногда администратор VMware vSphere задается вопросом о происхождении виртуальной машины - из какой родительской ВМ/шаблона она была клонирована? Вильям Лам разбирает это в своей статье, приведем вкратце его метод определения происхождения ВМ.

Как вы знаете, бывает три типа клонирования виртуальных машин в VMware vSphere:

• Full Clone - это полный клон, то есть независимая копия виртуальной машины, у которой нет ничего связанного с родительской ВМ, это просто ее полная копия.
• Linked Clone - это копия виртуальной машины, которая имеет общие диски с родительской, доступные на чтение (это экономит пространство и позволяет просто откатываться к родительскому образу). Уникальные данные эта машина хранит в собственных дельта-дисках.
• Instant Clone - это независимая копия виртуальной машины, которая начинает исполняться с какого-то момента и отделяется от основной машины. Для этого используются техники in-memory cloning и copy-on-write, которые используются также и для связанных клонов.

Чтобы найти источник клонированной машины, нужно проанализировать события vCenter Server Events. Вот какие они бывают касательно клонов:

• VmClonedEvent - появляется, когда происходит создание Full Clone или Linked Clone.
• com.vmware.vc.VmInstantClonedEvent - происходит при созданиии Instant Clone.
• VmDeployedEvent - вызывается, когда виртуальная машина развертывается из шаблона (vSphere Template или Content Library Template).

На базе анализа этих трех событий в истории vCenter Вильям Лам создал PowerCLI-функцию Get-VMCloneInfo, с помощью которой можно узнать родителя для виртуальной машины, если она была клонирована.

Устанавливаем ее простой командой:

Install-Script VMCloneInfo

На входе эта функция принимает имя ВМ, которую мы хотим проанализировать. Такой вывод мы получим, если машина не была клонирована:

> Get-VMCloneInfo -VMName "SourceVM"

Unable to find any cloning information for SourceVM, VM may not have been cloned or vCenter Events have rolled over

Так будет выглядеть вывод по полному клону:

> Get-VMCloneInfo -VMName "Full-Clone-VM"

  Type Source Date User

  ---- ------ ---- ----

Full SourceVM 1/3/2021 1:13:00 PM VSPHERE.LOCAL\Administrator

Так мы узнаем, что машина является связанным клоном:

> Get-VMCloneInfo -VMName "Linked-Clone-VM"

  Type Source Date User

  ---- ------ ---- ----

Linked SourceVM 1/3/2021 1:13:14 PM VSPHERE.LOCAL\Administrator

Так - что Instant-клоном:

> Get-VMCloneInfo -VMName "Instant-Clone-VM"

  Type Source Date User

  ---- ------ ---- ----

Instant SourceVM2 1/3/2021 1:12:44 PM VSPHERE.LOCAL\Administrator

Вот пример того, что машина была клонирована из шаблона vSphere Template:

> Get-VMCloneInfo -VMName "VMTX-VM"

  Type Source Date User

  ---- ------ ---- ----

Full SourceVMTXTemplate 1/3/2021 2:20:31 PM VSPHERE.LOCAL\Administrator

А вот - что из шаблона Content Library VM Template:

> Get-VMCloneInfo -VMName "VMTemplate-VM"

  Type Source Date User

  ---- ------ ---- ----

Full SourceVMTemplate 1/3/2021 2:23:41 PM VSPHERE.LOCAL\Administrator

Компания VMware выпустила недавно интересный документ "VMware vSphere 7.0 U1 Tagging Best Practices", описывающий улучшения, которые были сделаны в VMware vSphere 7.0 U1 в плане производительности операций при работе с тэгами.

Вкратце, было сделано 3 основных улучшения:

• Увеличена производительность при создании тэгов и категорий по сравнению с vSphere 6.7 U3.
• Производительность вывода тэгов через API улучшилась по сравнению с vSphere 6.7 U3.
• Теперь доступна паджинация вывода API, что позволяет упростить и ускорить получение данных.

Для иллюстрации улучшений на рисунке ниже приведена картина задержек (latency) при привязывании 15 тэгов к 5 000 виртуальным машинам в vSphere 6.7 U3 (где время линейно увеличивалось с ростом числа тэгов) и vSphere 7.0 Update 1, где время оставалось практически неизменным.

Скачать отчет VMware vSphere 7.0 U1 Tagging Best Practices можно по этой ссылке.

На сайте проекта VMware Labs обновилась еще одна интересная штука - средство Python Client for VMware Cloud on AWS 1.2, с помощью которого пользователям публичного облака VMware Cloud on AWS можно автоматизировать операции с инфраструктурой виртуального датацентра VMConAWS SDDC.

Это средство представляет собой не клиент для работы с сервером vCenter, а средство удаленного исполнения задач в облаке, таких как создание сетей или настройка групп и правил безопасности на шлюзах Management и Compute Gateways.

Вот небольшой обзор работы утилиты от ее автора Nico Vibert:

Также у него есть подробная статья об использовании этого средства для запуска задач в облачной среде. Список доступных команд Python Client for VMware Cloud on AWS доступен в инструкции.

Вот что нового появилось в версиях 1.2 и 1.1:

• Добавлен Dockerfile для построения Docker-образа, в котором будет запускаться PyVMC
• Добавлена видимость счетчиков исходящего (Egress) трафика
• Добавлена видимость таблицы маршрутизации
• Появилась поддержка L2VPN
• Появилась поддержка Nested Group
• Появилась поддержка распределенного сетевого экрана (Distributed Firewall)

Скачать Python Client for VMware Cloud on AWS 1.2 можно по этой ссылке.

Недавно компания VMware полностью переработала портал документации для разработчиков. Там произошел редизайн интерфейса, была улучшена категоризация, а также юзабилити в целом. При этом ранее документация по PowerCLI существовала отдельно от этого портала.

Теперь домашняя страница VMware PowerCLI полностью интегрирована в портал документации, а также получила много новых фич. Давайте на них взглянем:

1. Компоновка домашней страницы

Теперь с нее вы можете перейти на:

• Сообщество разработчиков
• Пример репозитория на GitHub
• Фиче-реквесты
• Блог PowerCLI
• Release notes
• Сhangelog
• Руководство пользователя

То есть это теперь простая и удобная, но функциональная стартовая страница.

2. Организация командлетов по продуктам

Ранее все командлеты были организованы по модулям, что было неудобно для пользователей. Теперь стало намного удобнее, потому что можно проваливаться в каталог командлетов по продуктам:

3. Глобальный поиск

Неважно, какой раздел вы смотрите сейчас, вы всегда сможете воспользоваться функцией глобального поиска:

4. Вкладка структуры данных

Разделы помощи ориентированы на объекты PowerCLI. Теперь на отдельной вкладке Data Structure можно увидеть, как эти объекты обрабатываются со стороны командлетов.

5. Категории

В рамках разделов по продуктам можно искать командлеты по понятным категориям из меню слева:

6. Страница CMDLET Reference

Эта страница позволяет понять как устроен командлет, и как он используется. Работает подсветка кода, и приведены простые примеры использования, которые вы можете скачать и уже самостоятельно изменять для получения наглядного результата. Вот пример такой страницы для командлета Connect-VIServer.

В общем - пользуйтесь.

Не все администраторы VMware vSphere и vSAN знают, что в версии vSAN 6.7 Update 3 появилась утилита vsantop, которая по аналогии с esxtop, используемой для получения метрик с хостов ESXi, позволяет получать метрики с устройств и хранилищ vSAN.

Запускается утилита просто: vsantop

По умолчанию она отображает метрики для сущности host-domclient. Чтобы выбрать нужную вам сущность - устройства, хост или кластер, нужно нажать большую клавишу <E> с шифтом:

После того, как вы выберете нужную сущность, будут отображаться метрики для нее с дефолтными колонками в данной категории. Чтобы выбрать колонки, нужно нажать клавишу <f>:

Для отображения можно выбрать только 10 полей, если хотите добавить какое-то поле, то какое-то из текущих придется убрать.

Также esxtop может работать в пакетном режиме с заданным интервалом и записывать метрики в CSV-файл:

vsantop -b -d [delay] -n [iterations] > [file location & name]

usage: vsantop [-h] [-v] [-b] [-d delay] [-n iterations]
    -h prints this help menu.
    -v prints version.
    -b enables batch mode.
    -d sets the delay between updates in seconds.
    -n runs vsantop for only n iterations. Use "-n infinity" to run forever.

Например, вот такая команда запустит сбор метрик с 10-секундным интервалом, всего будет 20 таких итераций, а результаты будут записаны в файл CSV:

vsantop -b -d 10 -n 20 > /vmfs/volumes/vsanDatastore/vsantop/result.csv

Большинство администраторов, которым требуется управление виртуальной инфраструктурой VMware vSphere с помощью сценариев используют интерфейс VMware PowerCLI, который является оберткой движка PowerShell. Это требует наличие отдельного хоста, с которого идет исполнение сценариев, а также часто требуются такие сервисы, как vRealize Orchestrator и vRealize Automation.

Поэтому, начиная с VMware vSphere 6.7, появился новый Open Source интерфейс для управления виртуальной средой - Script Runtime Service (SRS). Он представляет собой Kubernetes-приложение для управления инстансами PowerCLI и вызова командлетов через REST API.

Интерфейс SRS позволит интегрировать управление исполнением сценариев PowerCLI в vSphere Client для виртуальных машин и приложений.

SRS создает отдельное пространство имен в кластере Kubernetes, которое позволяет PowerCLI работать как Kubernetes pod. Этот легковесный PowerCLI pod реализуется как образ контейнера, который имеет все модули PowerCLI и требует только необходимые управляющие компоненты, трансформирующие ввод и вывод для сценариев, а также управляющие исполнением запрошенного сценария.

Первоначальная инсталляция SRS запускает задачу Kubernetes, которая регистрирует SRS в сервисах провайдера идентификации vSphere SSO. Единожды аутентифицированные клиенты SRS API автоматически включаются в список доверенных на серверах vCenter.

Надо отметить, что сейчас SRS находится еще в ранней стадии разработки и не работает с vSphere with Tanzu (поэтому не развертывайте его со службами Supervisor Cluster).

Попробовать работу с движком SRS можно двумя путями:

1. Устанавливаете SRS в кластере Kubernetes на любую из машин (инструкции здесь)

2. Устанавливаете SRS на специальным образом подготовленную виртуальную машину на базе Photon OS (инструкции тут).

Начать экспериментировать с SRS API можно, перейдя по ссылке:

https://{SRS-IP}/swagger/index.html

SRS использует механизм vCenter Server SSO для идентификации и аутентификации. У любого пользователя с доступом через SSO есть возможность настроить PowerCLI-соединения к серверам vCenter Servers. Как начать это делать описано вот тут.

SRS работает с vSphere 6.7 и более поздними версиями. Сообщить о проблемах вы можете вот тут, а также присодинившись к VMware Code и каналу в Slack.

В прошлом году мы писали о полезной утилите VMware Configuration Maximums Tool, которая позволяет выводить максимальные конфигурации для различных продуктов VMware. Эта очень полезная штука для администраторов vSphere умеет не только выводить список всех максимумов, но и сравнивать их для разных версий одного продукта.

Для этого нужно выбрать пункт меню "Compare Limits" и указать сравниваемые версии продуктов:

Штука эта очень удобная, но у нее есть большой недостаток - она выводит все конфигурации максимумов (для NSX-T, например, их 274 штуки, поэтому сложно отследить, что именно изменилось).

Поэтому Dale Coghlan написал интересный PowerCLI-модуль VMware.CfgMax, который решает эту проблему - в режиме командной строки можно узнать об изменениях максимумов, а также сделать еще несколько полезных вещей.

После установки модуля можно вывести список доступных продуктов, которые есть на configmax.vmware.com:

Для конкретного продукта можно вывести список его версий/релизов:

Также для конкретной версии можно вывести список категорий максимумов:

С помощью командлета можно вывести все максимумы для конкретного продукта и определенной его версии:

Можно вывести все конфигурации в рамках заданной категории:

Ну и, наконец, с помощью командлета Compare-CfgMaxLimits можно сравнить максимумы конфигураций для разных версий одного продукта:

Как вы видите, тут есть поле CompareStatus, которое и говорит нам, новая ли эта настройка (New), измененная по сравнению с прошлым релизом (Modified), нетронутая (пусто) или удаленная (Deleted) в новой версии.

С помощью параметра New можно, например, вывести все новые настройки:

Параметр Modified выведет только отличающиеся максимумы конфигураций:

Ну а параметр Deleted выведет устаревшие настройки:

Ну и все вместе, без неизмененных значений:

Очень удобная штука, все это также можно экспортировать в формат CSV и сравнивать в Excel. Для этого можно использовать следующую команду:

PS > $product = Get-CfgMaxProduct -Name 'NSX-T Data Center'
PS > $releaseA =  $product | Get-CfgMaxRelease -Version 'NSX-T Data Center 3.0.0'
PS > $releaseB =  $product | Get-CfgMaxRelease -Version 'NSX-T Data Center 3.1.0'
PS > Compare-CfgMaxLimits -Product $product -Release $releaseA -CompareRelease $releaseB | Export-Csv -Path compare-status.csv -NoTypeInformation

Скачать данный PowerCLI сценарий с примерами вы можете по этой ссылке.